The Web is becoming more interactive than it has ever been before. It is now possible to implement synchronous video conferencing applications running in a web browser either using plug-ins or new HTML5 (Hyper Text Markup Language) APIs (Application Programming Interfaces) which will become widespread in a near future. Eventually, this will make it possible to implement cost effective and highly customized solutions for various vertical markets—for example e-health—rather than having to use a big, generic, one-size-fit-all horizontal solution.
While video and audio conferencing running in a web browser makes it possible to communicate in new ways, it essentially turns the browser into a synchronous communication platform. This also leads users to expect that other parts of the application to also be a part of the communication. For example, in an e-health application, users may want to share diagrams, pictures, sensor data, text documents or even run web applications together with the other peers in a conference session. A natural complement is, therefore, some kind of synchronization framework that allows the users to share the content of web applications with each other.
FIG. 1 illustrates a shared workspace added to a dialer application to allow the user to share a web application during a phone call session.
Distributed Shared Memory referred to as DSM available on Ericsson Labs makes it possible to synchronously share web application in real-time with other users. In short, a DSM is a distributed global addressable memory space where every memory space is assigned a unique address. By knowing this address, it is possible to get a copy or reference to that memory.
A DSM can be implemented in two ways. The first way is to provide a centralized solution where the DSM resides on an external server. The main drawback with this approach is that client must acquire a lock to the server before making any changes in order prevent the memory from becoming corrupted. A drawback with locks is that only one user at a time can update the memory and all other clients must wait until the first client has finished its operations, thus making it unsuitable for implementing synchronous collaborative services.
The second approach is to let each client acquire a local copy or replica of the DSM and then synchronize the DSM in the background. Any modification to a particular DSM is synchronized so that every replica converges to the same state after some time.
Operational Transformation (OT) is a theoretical framework for optimistic concurrency control allowing clients to work locally on a data set and then synchronize changes with other clients and servers in the background. Typically, Operational Transformation provides transformation functions that decide how to resolve merge conflicts that can occur if multiple users edit the same data set at the same time. The fundamental idea is to transform incoming operations (e.g. add, del, set etc.) done by other clients while taking into account previously executed operations so that the system converges to the same state while also preserving the intention of each operation.
FIG. 2 shows an example where two users are editing a text document at the same time. In the example, the text is initialized to “abc”. The first user adds an “x” to the user's local document so that it becomes “xabc”. At the same time, the second user deletes the third character (index 3) so that the document becomes “ab”. They then forward the executed operations to each other. When the second user receives the operation done by first user it executes it, and the local document becomes “xab”.
However, when the first user receives the operation done by the second user, a merge conflict occurs. Since the first user has added a character to the beginning of the document, applying the DEL(2) operation would delete the “b” and not the “c”, which was not the intention of the second user. The solution to the merge conflict is to transform the DEL(2) operation so that it becomes DEL(3), due to the previously executed INS(0, X) operation.
A usage of Operational Transformation is to implement a distributed data storage such as a distributed shared memory or a distributed database where the OT server is viewed as master database and OT clients as replica clients. In the DSM framework, a local replica is referred to as a DSM Replica and the master database is referred to as DSM Master. Also, an application (for example the Shared Dialer Application) is using a DSM Replica 305, 308 via a user interface 304, 307 in a DSM Client 303, 306. A server 301 hosting a DSM Master 302 is referred to as a DSM Server. FIG. 3 depicts the relationship between DSM Clients 303, 306, DSM Servers 301, DSM Master 302 and DSM Replicas 305, 308. The DSM master 302 is identified by a DSM address 309
Any operation (get, add, delete and clear) done on a local DSM Replica is applied immediately without being delayed due to a server request or response. This makes it possible to implement responsive user interfaces without having to wait for lock on a central database.
OT resolves merge conflicts that occur if multiple applications update the same memory at the same time. In this way, each application can be completely unaware of each other. They just acquire a DSM Replica, which they then use to store and receive information without having to deal with synchronization issues or network signaling protocols to set up a session. Applications can also use a DSM Replica without it having to be fully initialized and replicated. In this case, any updates to the DSM are merged during the replication process.
The DSM framework creates DSM Master implicitly if they are requested by a DSM Client, i.e. there is no create function. Moreover, DSM Masters are automatically garbage collected if no DSM Clients are connected to them.
Web Connectivity1 is an Ericsson API and server to provide an overlay network in the application layer, enabling applications running in any context to have a uniquely addressable URI, and act as a server. These URIs are uniform for the application, regardless of whether it runs on a server or client, native or browser. One application of this is to create, on the fly, servers in web applications, running in a browser. Once the session ends, and the user navigates away from the current page, the server is shut down and becomes inaccessible.
Web applications typically require that data is stored in a database running on a web server. This web server may run an internal corporative network, or intranet, which is not accessible from the Internet. Also, since some data may be too sensitive to be stored on a public web server, it becomes difficult to develop collaborative software where some parties reside on a public networks and some on private intranet.
For example, in a collaborative e-health application it may be beneficial for a nurse to share medical records stored on a hospital database with patients connected to networks in their homes. Sharing such domain specific information in a web application is difficult today due firewalls and corporate policies. It also makes it difficult to use the exiting DSM solutions as it is required that the DSM Master (or OT server) runs on a centralized server on a public network.
A solution to this problem would be to run a DSM Server in the end-user device (web browser/native app), for example running on the nurse's web browser client. However, to make the communication flexible it should be possible to transfer DSM Server to another Web browser client, for example if the nurse leaves and, instead, a doctor joins the conference.
The need for centralized web servers can also impose a scalability problem. While content delivery networks such as Akamai can be used to accelerate the performance for some web applications, it is hard to use such caching mechanisms to improve performance for stateful web services such as DSM, which is dependent on the Operational Transformation's client/server model. In this case, it could sometimes be beneficial to run a DSM Server in browser clients on end user devices in a peer-to-peer style. Still, it should be possible to address the DSM Server in a unified style using the same addressing schema, independent if it is running in the web browser/native app or on a dedicated server.
However, while a peer-to-peer solution would work for two users for example using a shared dialer telephony application, it may not be beneficial for multiparty conferencing. In this case, it would be useful if it were possible to seamlessly migrate data between different DSM Masters during a session to upgrade the application to better support conferencing. For example, if more than two clients connect to the DSM Master running in a web browser, the data is transferred to a DSM Server running on dedicated server hardware thus reducing the network load of the client. This migration process should be completely transparent and not affect the user perceived performance.
Being able to seamlessly migrate data to another DSM storage could also be used for load balancing purposes, for example if a DSM server becomes overloaded.
Another reason to be able to migrate data between different storages would be to support management of data centers where a hosted DSM Server can be seamlessly transferred to another DSM Server in runtime. This would be useful if a particular server needs to be rebooted or replaced. To reduce network delay it can also be useful to transfer a DSM session to another data center residing closer to the user. This is an important requirement to be able to develop telecom-grade services, and is particular important for implementing the aforementioned shared dialer application which is expected to always work.
beWeeVee is a commercial OT-based project which attempts to provide a peer-to-peer variant, in order to alleviate the need to host servers for all clients. In beWeeVee, every client is configured to act as a server, and can accept other clients. The OT algorithm employed ensures the entire system of servers, if properly configured, eventually arrives at a consistent state. A drawback of pure peer-to-peer solution is that the system becomes much more complex to implement in contrast of adopting a migratable OT client/server model as proposed in this invention.
Dynamic Clients, Dynamic Partitions, Locking and Migration capability for distributed server for real-time collaboration is shown in U.S. Pat. No. 6,336,134 B1. U.S. Pat. No. 6,336,134 B1 uses some kind of locking mechanism to partition a shared workspace among multiple server processes. Support for Operational Transformation and optimistic concurrency control is not discussed. Moreover, the solution of U.S. Pat. No. 6,336,134 B1 does not operate on top of an overlay network so it is not clear how to migrate a process to an end-user device such as web browser. The solution is based on history logging, which means that it will always be an interruption when switching data source.